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QuickDraw  Data  Structures  for  Image  Processing 


PERRY  J.  LAPOTIN  AND  HARLAN  L.  MCKIM 


INTRODUCTION 

Import  and  export  formats  for  both  Landsat 
and  SPOT  imagery  are  widely  supported  within 
the  image-processing/remote-sensing  community 
(Holkenbrink  1978,  SP07  /  .age  1983).  These 
formats  provide  a  standard  tov  uat  for  the  flow  of 
information  between  various  hosts,  but  are  poorly 
suited  to  fast  image-processing  at  the  microcom¬ 
puter  level  (Cohen  and  Grossberg  1983,  Winston 
1984,  Rumelhart  and  Zipser  1985,  McClelland 
and  Rumelhart  1987). 

In  this  study,  a  new  graphically  dependent 
method  for  converting  binary  information  into 
QuickDraw*  operating  codes  is  investigated.  The 
technique  converts  pixels  of  variable  gray  scale 
(usually  9-255)  into  scaled  RGB  intensities.  The 
scaled  intensities  are  stored  within  a  pixel  map 
that  contains  information  on  the  base  address  of 
where  the  information  may  be  retrieved  from 
memory  as  well  as  information  on  the  size,  hori¬ 
zontal  and  vertical  resolution,  and  planar  offsets 
(for  greater  than  8-bit  color).  In  the  developed 
prototype,  pictures  are  referred  to  by  their  handle 
in  memory  (pointers  to  master  pointers  that 
point  to  the  picture  data  structure  in  memory). 
These  handles  may  appear  clumsy  at  first,  but 
they  are  needed  to  quickly  pull  large  volumes  of 
information  from  memory  in  the  image  display 
process.  Furthermore,  it  will  become  apparent 
that  they  are  needed  for  the  design  of  efficient 
and  dyneunic  data  structures  to  display,  overlay, 
and  analyze  large  scenes  in  multiple  windows 
(GrafPorts).  GrafPorts  are  the  “logical  paper” 
required  to  display  images  in  windows,  dialogs, 
and  on  most  output  devices.  The  data  structure  is 


*  QuickDraw  is  the  graphical  operating  language  for  the 
Apple  Macintosh.  This  paper  assumes  that  the  reader  is 
familiar  with  structured  programming  techniques  and  has 
some  familiarity  with  memory  management  methods.  For 
additional  information  on  handles  and  QuickDraw  refer  to 
Inside  Macintosh  (1985). 


defined  in  Figure  1  and  a  detailed  description 
may  be  found  in  Inside  Macintosh  (1985). 
GrafPorts  that  contain  pixel  maps  may  be  quickly 
converted  to  their  vector  equivalent  using  stan¬ 
dard  picture  data  structures  and  “off-the-shelP 
bit  transfer  routines. 


METHOD 

All  image  data  is  sequential,  so  they  may  be 
handled  in  a  systematic  manner  depending  on 
the  specific  input  format  (e.g.  BSQ,  BIL,  BIP, 
BIPP).  Binary  data  are  converted  to  a  picture 
handle  by  first  “spooling-in”  the  information  as  a 
raster  image  to  either  an  on-screen  (visible  to  the 
user)  or  off-screen  (invisible  to  the  user)  pixel 
map.  This  is  accomplished  in  the  following 
maimer. 

1.  A  pointer  of  dynamic  size  (or  fixed  to  a 
segment  size  of  the  image)  is  created  in  memory 
to  store  the  image  bytes  temporarily  prior  to 
display.  This  image  size  dictates  the  number  of 
segments  needed  to  ’  ead  in  the  information. 
Since  large  scenes  require  large  memory  alloca¬ 
tion  (e.g.  1024  X  1024  requires  1,048,576  bytes), 
segments  of  variable  size  (e.g.  32,000  bytes)  are 
used  and  the  memory  is  freed  after  each  read-in 
sequence.  This  implies  thav  segment  pointers  are 
either  disposed  of  or  re-indaxed  (to  the  begiiming 
using  ordinal  operators)  following  each  segment 
read. 

2.  After  reading  in  a  segment,  the  binary 
(represented  in  character  form)  for  each  pixel  in 
the  segment  is  converted  to  its  ordinal  value  in 
the  0-255  range.  The  ordinal  values  are  used  to 
create  a  color  range  for  display  of  the  information 
into  the  GrafPort. 

3.  Each  pixel  in  the  0-255  range  is  converted 
to  the  RGB  color  range  specified  by  QuickDraw. 
Therefore,  each  pixel  in  the  0-255  range  requires 
conversion  to  the  RGB  color  format  of  Figure  2. 
Note  that  RGB  color  is  composed  of  separate  red, 
green,  and  blue  intensities,  and  a  color  specifica- 


CDialogPtr  =  CWindowPtr; 
CWindowPtr  =  CGrafPtr; 


CGrafPtr  =  ''CGrafPort; 

CGrafPort  =  RECORD 

portPixMap:  pixMapHandle; 


END; 


pixMapHandle  =  ‘^pixMapPtr;  {  handle  to  a  pixel  map) 
pixMapPtr  =  '^pixMap; 
pixMap  =  RECORD 


baseAddr  ;  Ptr; 
rowBytes  :  INTEGER; 
Bounds  :  Rect; 
pm  Version  :  INTEGER; 
packType  :  INTEGER; 
packSize  :  LONGINT; 
hRes  :  Fixed; 
vRes  :  Fixed; 
pixelType  :  INTEGER; 
pixelSize ;  IN'!  EGER; 
cmpCount :  INTEGER; 
cmpSize :  INTEGER; 
planeBytes :  LONGINT; 
pmTable :  CTabHandle; 
pmReserved :  LONGINT; 

END; 


(  pointer  to  pixels) 

{  offset  to  next  line) 

(  encloses  bitmap) 

I  pixMap  version  number) 

1  defines  packing  format) 

{ length  of  pixel  data) 

1  horiz.  resolution  (ppi)) 

I  vert,  resolution  (ppi)) 

(  defines  pixel  type) 

1  no.  of  bits  in  pixel) 

1  no.  of  components  in  pixel) 

1  no.  of  bits  per  component) 

1  offset  to  next  plane) 
j  color  table  for  this  pixMap) 

1  for  future  use.  MUST  BE  0) 


Figure  1.  RGB  color  GrafPorts  under  QuickDraw.  Pixel  /naps  to  store  i/ifonnation  on 
memory  location  (baseAddr),  number  of  bytes  per  row  (rowBytes),  and  the  minimwn  I'ectangle 
that  bounds  the  image  (Bounds).  The  remaining  fields  are  used  to  specify  packing  fonnats, 
resolution,  bit  planes,  and  indexes  to  color  lookup  tables  (CLUTs). 


tion  table  can  be  set  up  to  determine  equivalent 
RGB  color  for  a  particular  index  value.  Since 
RGB  color  is  composed  of  three  separate  fields,  a 
single  band  of  the  image  data  can  be  “loaded”  into 
a  single  gun  (e.g.  only  the  red  display)  and  viewed 
in  one  color  range.  A  false  representation  (of  the 
true  color  composite)  can  be  created  for  a  single 
band  by  loading  the  remaining  two  color  fields 
with  index  values  derived  from  the  single  0-255 
intensity.  Conversely,  three  bands  of  informa¬ 
tion  can  be  read  to  create  a  “true”  false  color 
composite.  In  either  case,  the  0-255  range  needs 
to  be  converted  to  the  integer  scale  (-32676  to 
32676)  to  achieve  a  full  dynamic  range  of  color. 
For  density  slicing,  a  subrange  of  the  0-255 


range  is  chosen  and  expanded  to  the  integer 
scale.  Hue,  saturation,  and  brightness  may  be 
changed  independent  of  the  RGB  color  selection. 

4.  Pixels  in  the  segment  (e.g.  the  block  of 
32,000  bytes)  are  converted  to  their  QuickDraw 
RGB  equivalents  and  are  displayed  within  an  on¬ 
screen  or  off-screen  GrafPort.  A  GrafPort  is  the 
basic  data  structure  for  storing,  manipulating, 
and  displaying  information  within  a  window 
that  may  contain  both  horizontal  and  vertical 
scroll-bars.  In  the  QuickDraw  environment,  both 
dialogs  and  windows  are  pointers  to  GrafPorts 
and  are  simply  special  versions  of  the  basic  data 
structure.  Figure  1  shows  the  pixMap  data  struc¬ 
ture  of  the  GrafPort  using  the  Color  QuickDraw 
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RGBColor  =  RECORD 

red :  INTEGER; 
green ;  INTEGER; 
blue  :  INTEGER; 

END; 

ColorSpec  =  RECORD 

value  ;  INTEGER; 
rgb  :  RGBColor; 

END; 


I  magnitude  of  red  component) 

I  magnitude  of  green  component) 
{  magnitude  of  blue  component) 


index  or  other  value) 
true  color) 


Figure  2.  RGB  color  format  under  QuickDraw.  Binary  data  are  scaled  to  the 
range  of  integers  for  separate  red,  green,  and  blue  display. 


environment.  For  the  sake  of  clarity,  only  the 
portPixMap  data  structure  is  shown  in  its  en¬ 
tirety.  There  are  many  fields  within  the  color 
GrafPort,  ranging  from  device  specifications  to 
fore-  and  background  color  specifications.  For  ad¬ 
ditional  information,  see/nsiVfeAfacintosA  (1987). 

As  previously  mentioned,  color  windows 
iCWindowPtr)  and  color  dialogs  (CDialogPtr) 
are  simply  equivalent  to  color  GrafPorts 
iCGrafPtr).  The  single  field  shown  within  the 
color  GrafPort  structure  is  the  port  pixel  map, 
which  contains  all  the  specifications  for  the  ras¬ 
ter  form  of  the  image  data.  To  refer  to  this 
information,  a  handle  (the  pointer  to  a  pointer,  a 
method  called  “double  inflection”)  is  used.  The 
handle  points  to  a  “master  pointer”  that  keeps 
track  of  memory  locations.  ^  In  this  manner,  win- 


^  One  might  consider  the  master  pointer  as  a  postman  trying 
to  deliver  your  mail.  The  postman  points  to  your  house  and 
its  contents,  and  the  post  office  points  to  the  postman  to  give 
him  the  mail: 

PostOffice  :  ^Postman  !a  postoffice  is  a  pointer 
to  the  postman) 

PostMan  :  MyHouse  (the  postman  is  a  pointer  to 
my  house  and  its  contents) 

MyHouse  =  RECORD  Ifinally,  my  house  contains 
my  items  and  specifications) 

myCouch  :  SleepeiType; 
myDog :  HoundType; 
myCar  :  VWType; 

END; 

The  use  of  double  inflection  becomes  important  in  an  envi¬ 
ronment  where  one  click  of  the  mouse  switches  between 
windows  (GrafPorts),  and  scrollbars  pan  information  up  and 
down  and  side  to  side  instantaneously.  Efficient  data  struc¬ 
tures,  efficient  memory  address  management,  and  master 
pointing  are  required  (Forsyth  and  Rada  1986). 


dows  and  dialogs  are  attached  to  GrafPorts  that 
hold  the  information  needed  to  recreate  the  image 
simply  by  pointing  to  necessary  fields  within  the 
data  structure.  A  procedure  that  just  transfers 
pixel  bytes  may  be  used  to  swap  the  image  in  and 
out  of  memory  quickly  without  reloading  the 
scene  or  recalculating  the  RGB  equivalent  inten¬ 
sities. 

5.  Once  all  segments  for  the  image  are  con¬ 
verted  to  their  RGB  equivalent  in  step  4  and  the 
pixel  map  is  loaded  with  the  image,  it  either 
remains  within  the  CGrafPtr  data  structure  or  it 
may  be  “spooled”  into  a  picture  to  convert  it  to  a 
vector  equivalent.  The  vector  equivalent  for  the 
rasterized  pixel  map  is  simply  a  vector  represen¬ 
tation  of  the  raster  block.  This  implies  that  con¬ 
version  is  just  a  conversion  of  data  types  and  is 
limited  in  the  actual  vectorization.  More  in-depth 
vectorization,  such  as  bezier  curve  tracing,  can 
always  be  done  after  the  initial  raster-to-vector 
conversion  using  off-the-shelf  software,  such  as 
Digital  Darkroom  (1988)  and  Adobe88  (1988). 

The  picture  is  a  dynamic  record  of  QuickDraw 
operating  codes  (opcodes)®  listed  in  Appendix  A. 
The  data  structure  is  dynamic  from  two  perspec¬ 
tives: 

•  Its  size  is  bounded  only  by  available  mem¬ 
ory 

•  The  structure  is  a  handle  and  is  thus  a 
dynamic  memory  address. 

Specifically,  the  data  structure  is  defined  in 
Figure  3.  The  picture  definition  data  consider  all 


®Variable-sized  “action  items”  tliat  trigger  a  drawing  opera¬ 
tion.  The  codes  are  passed  directly  to  an  output  device 
(screen,  printer)  for  high-speed  display,  and  are  stored  in 
compressed  form  within  the  PICT  and  PICT2  format. 
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picHandle  =  '^picPtr; 
picPtr  =  '^Picture; 

Picture  =  RECORD 

picSize ;  INTEGER; 
picFrame ;  Rect; 

{then  picture  definition  data — ^the 
QuickDraw  opcodes) 

END; 


Figure  3.  The  picture  handle  data  structure  used 
to  store  and  display  images  in  both  raster  and 
vector  format. 


SPOTPict:  =  picHandle(NewHandle(SizeoftPicture)));  with 
SPOTPict  DO 
BEGIN 

picSize  ;=  SizeofiPicture);  (dynamic,  so  don’t  worry) 

picFrame  ;=  SPOTRect;  (e.g.  1024  x  1024) 


I _ _ i 

Figure  4.  Memory  must  be  allocated  for  the  picture  handle  to  receive 
the  image  and  provide  the  required  space.  The  Sizeof  function  creates 
anew  handle  in  memory  and  specifies  a  temporary  picture  size.  The  real  size 
of  the  picture  expands  to  fit  the  actual  size  of  the  image. 


data  to  be  in  vector  format  and  handle  raster 
images  as  a  special  vector  style.  Therefore,  im¬ 
ages  that  were  created  as  a  series  of  arcs,  lines, 
polygons,  and  other  vector  drawing'^  get  stored  as 
vector  simply  because  they  were  created  that 
way.  Raster  images  (e.g.  MacPaint)  are  stored  as 
raster  using  vector  operations  (e.g.  a  pixel  is 
simply  a  rectangle  of  unit  size). 

The  data  structure  allows  for  the  import  of  im¬ 
agery  simply  by  specifying  the  image  size  (picSize) 
and  the  minimum  bounding  rectangle  that  en¬ 
compasses  the  image  (picFrame),  Since  the  size  of 
the  structure  is  dynaunic,  picSize  can  be  dynami¬ 
cally  allocated  to  force-fit  the  image  using  the 
Sizeo/" function  (standard  in  Pascal  and  C).  For 
example,  if  SPOTPict  is  of  t5rpe  picHandle  in  Fig¬ 
ure  3,  then  a  dynamic  picture  size  may  be  allocat¬ 
ed  using  the  expression  SPOTPict'^^.  picSize  :  = 
Sizeof  (Picture).  In  practice,  however,  memory 
must  be  allocated  to  all  assignments  for  the  pic¬ 
ture  handle  using  the  NewHandle  operator  (Fig. 
4). 

In  sum,  picture  handles  are  used  to  swap 
imagery  quickly  in  and  out  of  memory  for  fast 
image  display.  Since  each  picture  handle  contains 
the  opcodes  that  were  used  to  create  it,  no  in¬ 
formation  is  lost  from  the  original  binary  data. 
The  PICT2  format  for  import  and  export  of  im¬ 
agery  is  simply  an  extension  of  the  picture  hjuidle 


data  structure  with  a  512-byte  header.  This  as¬ 
sociation  between  picture  handles  and  the  Quick¬ 
Draw  import/export  standard  provides  a  quick 
and  efficient  method  for  spooling  large  volumes 
of  information  into  (and  out  of)  a  PICT2  data  file. 


PICTURE  FILES 

Picture  handles  may  be  quickly  converted  to 
picture  documents  (alias  MacDraw  PICT)  by 
writing  the  information  from  the  handle  into  an 
open  file.  Figure  5  shows  the  basic  construction 
of  a  PICT  (black  and  white)  and  a  PICT2  data  file 
(extended  size  and  color). 

Segments  of  a  data  file  that  contain  specific 
information  styles  are  called  forks.  Resource 
forks  typically  contain  the  “raw”  numerical  in¬ 
formation  necessary  for  the  graphical  procedure 
(e.g.  the  bits  necessary  to  draw  an  icon  or  the 
specification  necessary  to  show  a  dialog  box). 
For  the  PICT2  format,  only  the  data  fork  con¬ 
tains  any  information  and  the  resource  fork  is 
empty.  Within  the  data  fork,  the  format  of  the 
file  is  sequential  of  the  form:  1)  a  512-byte 
header,  2)  the  picture  size  in  bytes,  3)  a  mini¬ 
mum  bounding  rectangle,  4)  the  opcodes,  and  5) 
an  End  of  Picture  Marker  =  $00FF. 

To  import  imagery  from  an  open  picture  file. 
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a  spooling  routine  is  used  to  handle  the  header 
and  read  the  opcodes  into  a  previously  allocated 
picture  handle.  An  outline  of  this  method  is 
provided  in  Figures  6  and  7.  Figure  6  is  a  short 
procedure  that  simply  reads  in  information  from 
a  previously  open  file  whose  reference  number  is 
the  variable  Refnurn.  In  Figure  7,  this  procedure 
is  used  as  a  graphical  procedure  to  spool  in  the 
information  from  the  file. 

Images  are  exported  from  a  picture  handle  in 
the  reverse  manner  from  how  they  were  read  into 
the  picture  handle.  Figures  8  and  9  give  ex¬ 
amples  of  this  process  using  the  procedure 
RutPICTData  as  the  graphical  procedure  for  the 
write  process,  and  the  fnnctionWritelmage  to 
write  the  image  from  the  picture  handle  ithePict ) 
into  a  PICT2  file  whose  reference  number  is 
RefNum. 

In  sum,  the  PICT2  data  file  is  a  simple  exten¬ 
sion  of  the  picture  handle  data  structure  pro¬ 
vided  in  Figure  3.  It  represents  a  powerful  data 
format  for  processing  large  volumes  of  informa¬ 
tion  from  files  that  are  flexible  both  in  size  and  in 
data  structure  (raster  and  vector).  In  addition, 
the  format  is  recognized  as  a  standard  for  the  im¬ 
port  and  export  of  graphical  information  to  other 
image-processing  software. 


PROCEDURE  GetPictData  (dataPtr  ;  Ptr;  byteCount :  longint); 

I  VAR 

j  longCount ;  LONGINT; 

!  ReadErr ;  OSErr; 

I  BEGIN 

longCount  :=  byteCount; 

I  ReadErr  :=  FSReadCRefNum,  longCount,  dataPtr); 

Ino  readErr  handling  here...) 

END ;!  GetPictData ) 

Figure  6.  A  short  procedure  to  read  a  specified  amount  of  information 
(b3rteCount)  into  a  data  pointer  (dataPtr)  from  a  previously  opened 
file  (RefNum). 


PICT2file 
(type=PICT) 

Data  Fork  Resource  Fork 

512-b3rte 
header 

picSize 

picFrame 
opcode 
picture  data 

opcode 
picture  data 
EndOfPicture 

Figure  5.  PICT  and  PICT2  file  format  for 
import  and  export  of  picture  data. 


This  fork 
is  empty 
in  PICT 
files 
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FXJNCTION  ReadPICT;  {(RefNum  :  INTEGER;  aWindow  :  WindowPtr) ;  boolean;!  1 
CONST 

PICThead  =  512;  (512  b3rtes  to  start  things  off) 

VAR 

ReadErr :  OSErr; 

Count:  LONGINT;  I 

thePict :  picHandle;  j 

myReadftocs  :  cqdProcs; 

BEGIN 

MaxApplZone;  I 

ReadErr  :=  SetFPos(RefNum,  fsFromStart,  0);( } 

SetStdCProcs(myReadProcs);{  1  j 

aWindow'^.grafProcs  ;=  @myReadProcs;{ ) 
myReadProcs.putPicProc  :=  @GetPICTData;( ) 

(for  now,  skip  the  header  and  read  the  size  of  the  picture  field;  we  Ccin  discard  this  since 
the  hounds  of  the  picture  frame  are  actually  used  to  determine  the  number  of  bytes  to 
be  read  into  the  picture  handle...) 

ReadErr  :  =  SetFPos(RefNum,  fsFromStart,  PICThead);  j 

(create  room  in  memory  for  the  new  picture) 
thePict  :=  picHandle(NewHan^e(Sizcof(Picture)));( ) 

Count  :=  SizeofiPicture); 

IF  (FSRead(RefNum,  Count,  Ptr(thePi-t''))  =  noErr)  THEN) } 

BEGIN  I 

ReadErr  :=  SetFPos{RefNum,  fsFromStart,  PICThead); 

Count  :=  thePict ‘^''.picSize; 

IF  (FSRead(RefNum,  Count,  Ptr( thePict'"'))  =  noErr)  ' 

THEN  ReadPICT  :=  true  | 

ELSE  (handle  the  bad  read  and  the  bad  news...) 

ReadPICT  :=  false;  i 

END;  1 

aWindow''.grafProcs  :=  NIL;( )  i 

ReadErr  :=  FSClose(RefNum); 

END;(ReadPICTl 


Figure  7.  A  procedure  to  spool  picture  data  into  a  picture  handle  (thePict).  The  procedure  uses  GetPICTData 
(Fig.  6)  as  a  graphical  procedure  and  FSRead  (Inside  Macintosh  1987)  to  read  in  the  basic  data  (operating  codes). 


1  PROCEDURE  PutPICTData  (dataPtr  :  Ptr;  b3daCount :  integer); 
i  VAR 

WriteErr :  OSErr; 
longCount :  LONGINT; 

BEGIN 

longCount  :=  byteCount; 

WriteErr  :=  FSWrite(RefNum,  longCount,  dataPtr);)  ) 

(handle  errors  in  Writelmage) 

END;(PutPICTData! 


Figure  8.  A  short  procedure  to  write  a  specified  amount  of  information 
(byteCount)  from  a  data  pointer  (dataPtr)  into  a  previously  opened  file 
(RefNum). 
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FUNCTION  Writelmage  (RefNum  :  integer) :  OSErr; 

CONST 

PICThead  =  512;  {512  bytes  to  start  things  oft) 

PICTtail  =  2; 

TYPE 

j  DiskBlk  =  PACKED  AIIRAY[1  ..BlokSize]  OF  qdByte; 

I  VAR 

1  WriteErr :  OSErr; 

dstBuf ;  DiskBlk; 

Count :  LONGINT; 

I  thePict ;  PicHandle; 

i  myProcs  :  cqdProcs; 

I  TailBlk  :  ARRAY[l..PICTtail]  OF  Byte; 

j  BEGIN 

I  WriteErr  :=  SetFPos(ReINum,  fsFromStart,  0); 

j  SetStdCProcs{myProcs); 

j  aWindow'^.grafProcs  :=  ©myProcs; 

myProcs.putPicProc  :=  ©PutPICTData; 

Count  :=  PICThead; 

(place  all  translation  information  in  the  dstBuf  so  that 
it  can  be  written  into  the  picture  header.  This  tells  the 
software  how  the  image  was  converted  from  binary  to 
!  PICT  for  future  reference,  and  rewrite  back  to  binary) 

j  WriteErr  :=  FSWrite(RefNum,  Count,  ©dstBuf); 

'  {thePict  is  the  picture  handle  with  opcodes) 

!  Count  :=  SizeofIthePict); 

!  WriteErr  :=  FSWrite(RefNum,  Count,  Ptr( thePict^));!  ) 

{write  EOF  opcode  for  PICT2  files) 
i  TailBlk[l]  :=  $00; 

I  TailBlk[2]  ;=  $FF; 

Count  :=  PICTtail; 

WriteErr  :=  FSWrite(RefNum,  Count,  ©TailBlk); 

I 

I 

aWindow'^.grafProcs  :=  NIL; 

{heuidle  write  errors  elsewhere) 

Writelmage  :=  WriteErr; 

END ;  { W  ritelmage ) 


Figure  9.  A  procedure  to  write  PICT2-style  files  from  a  picture  handle  (thePict)  and  force 
the  required  End  Of  Picture  marker.  The  512-byte  header  documents  how  the  image  was 
created  from  the  original  binary  (e.g.  the  conversion  from  the  original  0-255 used  to  create  the  RGB 
display).  If  additional  information  is  required  to  document  the  picture,  the  resource  fork  (Fig.  5) 
is  used  as  the  depository  for  the  information. 
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RESULTS 

A  protot3rpe  application  has  been  developed  to 
convert  image  data  into  PICT2  format.  While 
this  application  is  still  in  its  infancy,  results  in¬ 
dicate  that  there  is  a  significant  improvement  in 
microcomputer  image-processing  performance  as 
a  result  of  the  conversion.  Early  benchmarks  for 
a  512  X  512  SPOT  image  on  a  Macintosh  II  (with 
2  megabytes  of  memory  and  3  bands  open)  sug¬ 
gest  that  images  may  be  displayed  and  redrawn 
in  fractions  of  a  second.  Comparable  images  typ¬ 
ically  require  4  minutes  to  load  from  binary  and 
are  ill-suited  for  d3niamic  display  in  multiple 
windows.  Early  results  for  data  compression  in¬ 
dicate  that  vector  overlays  may  be  compressed  in 
memory  by  a  factor  of  8  (from  comparable  MOSS 
polygon  files)  and  SPOT  images  (depending  on 
scene  diversity)  by  a  factor  of  2.  Data  compres¬ 
sion  for  import  and  export  indicates  that  images 
may  be  saved  in  the  PICT2  format  at  roughly 
90%  of  their  binary  size  (again  depending  on  im¬ 
age  diversity).  Preliminary  testing  of  the  soft¬ 
ware  illustrates  that  images  may  be  displayed  in 
multiple  overlapping  windows  with  active  verti¬ 
cal  and  horizontal  scrolling  of  RGB  color.  Fur¬ 
thermore,  images  may  be  cut,  copied,  and  pasted 
at  variable  zoom  and  resolution  levels  between 
windows  and  the  scrapbook  using  standard  “scrap 
management”  and  QuickDraw  procedures. 

CONCLUSIONS 

While  the  PICT2  format  will  not  replace  the 
binary  structure  for  the  strict  import  and  export 
of  image  data,  it  accelerates  greatly  the  speed 
and  memory  performance  of  digitail  image  proces¬ 
sing  on  certain  hosts.  In  this  study,  data  struc¬ 
tures  have  been  derived  that  may  be  used  to  proc¬ 
ess  images  and  import  or  export  image  data  in  a 
format  compatible  with  other  commercial  soft¬ 
ware.  Advantages  of  this  approach  include: 

1)  compatibility  with  most  PostScript-  and 
QuickDraw-based  software, 

2)  very  fast  graphical  processing, 

3)  flexible  data  compression, 

4)  flexible  data  structuring  (dynaimic  size  and 
memory  allocation), 

5)  no  loss  of  information  from  original  binary 
form,  and 

6)  flexible  resolution,  hue,  saturation,  bright¬ 
ness,  and  bit-plane  «pecifications. 

Future  efforts  wiu  include  faster  data  conver¬ 
sion  into  the  PICT2  format  by  generating  operat¬ 


ing  codes  directly  from  the  input  stream  (they  are 
currently  generated  from  the  GrafPort  that  dis¬ 
plays  the  input  stream).  This  should  accelerate 
binary-to-picture  conversion  by  a  factor  of  2  and 
eliminate  the  need  to  use  the  GrafPort  as  an  in¬ 
termediate  buffer.  In  addition,  new  utilities  will 
include  image  export  into  the  PNTG,  PHCA, 
EPS,  and  TIFF  formats.  These  formats  provide 
an  export  technique  for  quick  image-processing 
using  video  (TIFF)  and  page-layout  software 
(PNTG,  PHCA).  Furthermore,  the  Postscript  com¬ 
patibility  (EPS)  will  provide  a  convenient  route 
for  exporting  images  into  UNIX  and  other  op¬ 
erating  systems  that  support  Postscript  but  not 
QuickDraw. 
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APPENDIX  A 

QuickDraw  Operating  Codes  (opcodes) 
for  converting  binary  image  data  into 
PICT  and  PICT2  Data  Files. 

Source:  Inside  Macintosh  (1987) 
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Table  A.  Data  types. 


Type 

Size 

vl  opcode 

1  byte 

v2  opcode 

2  bytes 

integer 

2  bytes 

long  integer 

4  bytes 

mode 

2  bytes 

point 

4  b}d£S 

0...255 

1  byte 

-128...127 

1  byte  (signed) 

rect 

8  bytes  (top,  left,  bottom,  right;  integer) 

poly 

10+  bytes 

region 

10+  bytes 

fixed-point  number 

4  bytes 

pattern 

8  bytes 

rowBytes 

2  bytes  (always  an  even  quantity) 

Opcode^'^ 

Name 

Table  B.  PICT  opcodes. 

Description 

Data  Size 
(in  bytes) 

$0000 

NOP 

nop 

0 

$0001 

CUp 

clip 

region  size 

$0002 

BkPat 

background  pattern 

8 

$0003 

TxFont 

text  font  (word) 

2 

$0004 

TxFace 

text  face  (byte) 

1 

$0005 

TxMode 

text  mode  (word) 

2 

$0006 

SpExtra 

space  extra  (fixed  point) 

4 

$0007 

PnSize 

pen  size  (point) 

4 

$0008 

PnMode 

pen  mode  (word) 

2 

$0009 

PnPat 

pen  pattern 

8 

$000A 

FiUPat 

fill  pattern 

8 

$000B 

OvSize 

oval  size  (point) 

4 

$000C 

Origin 

dh,  dv  (word) 

4 

$000D 

TxSize 

text  size  (word) 

2 

$000E 

FgColor 

foreground  color  (long) 

4 

$000F 

BkColor 

background  color  (long) 

4 

$0010 

TxRatio 

numer  (point),  denom  (point) 

8 

$0011 

Version 

version  (byte) 

1 

$0012 

♦BkPixPat 

color  background  pattern 

variable: 
see  Table  C 

$0013 

♦PnPixPat 

color  pen  pattern 

variable: 
see  Table  C 

$0014 

*FillPixPat 

color  fill  pattern 

variable; 
see  Table  C 

$0015 

♦PnLocHFrac 

fractional  pen  position 

2 

$0016 

♦ChExtra 

extra  for  each  character 

2 

$0017 

Q  A 

♦reserved  for  Apple  use  opcode  ’ 

0 

$0018 

♦reserved  for  Apple  use  opcode 

0 

$0019 

♦reserved  for  Apple  use  opcode 

0 

$001A 

♦RGBFgCol 

RGB  foreColor 

variable; 
see  Table  C 

$001 B 

♦RGBBkCol 

RGB  backColor 

variable: 
see  Table  C 
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Table  B  (conf d). 


Opcode 

Name 

Description 

Data  Size 
(in  bytes) 

$001C 

*HiliteMode 

hilite  mode  flag 

0 

$001D 

♦HiliteColor 

RGB  hilite  color 

variable: 

see  Table  C 

$001E 

♦DefHilite 

Use  default  hilite  color 

0 

$001 F 

♦OpColor 

RGB  Opcolor  for  arithmetic  modes 

variable: 

see  Table  C 

$0020 

Line 

pnLoc  (point),  newPt  (point) 

8 

$0021 

LineFrom 

newPt  (point) 

4 

$0022 

ShortLine 

pnLoc  (point,  dh,  dv  (-128. ..127) 

6 

$0023 

ShortLineFrom 

dh,dv(-128...127) 

2 

$0024 

^reserved  for  Apple  use  opcode’**^  +  2  bytes  data  length  +  data 

2+  data 

length 

$0025 

*re8erved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 

2+  data 

length 

$0026 

^reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 

2+  data 

length 

$0027 

*Fe8erved  for  Apple  use  op<^e  +  2  b3des  data  length  +  data 

2+  data 

length 

$0028 

LongText 

txLoc  (point),  count  (0..255),  text 

5  +  text 

$0029 

DHText 

dh  (0...255),  count  (0..255),  text 

2  -1-  text 

$002A 

DVText 

dv  (0...255),  count  (0...255),  text 

2  -4-  text 

$002B 

DHDVText 

dh,  dv  (0...255),  count  (0.255),  count,  text 

3  +  text 

$002C 

•reserved  for  Apple  use  opcode^*^  +  2  bytes  data  length  +  data 

2+  data 

length 

$002D 

*re8erved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 

2-t-  data 
length 

$002E 

•reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 

2-t-  data 

length 

$002F 

•reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 

2■^  data 

length 

$0030 

firameRect 

rect 

8 

$0031 

paintRect 

rect 

8 

$0032 

eraseRect 

rect 

8 

$0033 

invertRect 

rect 

8 

$0034 

fillRect 

rect 

8 

$0035 

•reserved  for  Apple  use  opcode^’^  +  8  bytes  data 

8 

$0036 

•reserved  for  Apple  use  opcode  +  8  bytes  data 

8 

$0037 

♦reserved  for  Apple  use  opcode  +  8  bytes  data 

8 

$0038 

frameSameRect 

rect 

0 

$0039 

paint  SameRect 

rect 

0 

$003A 

eraseSameRect 

rect 

0 

$003B 

invertSameRect 

rect 

0 

$003C 

RllSameRect 

rect 

0 

$003D 

♦reserved  for  Apple  use  opcode'*’ 

0 

$003E 

•reserved  for  Apple  use  opcode 

0 

$003F 

•reserved  for  Apple  use  opcode 

0 

$0040 

frameRRect 

rect® 

8 

$0041 

paintRRect 

rect® 

8 

$0042 

erase  RRect 

rect® 

8 

$0043 

invertRRect 

rect® 

8 

$0044 

fillRRect 

rect® 

8 

$0045 

♦reserved  for  Apple  use  opcode  ’  +  8  bytes  data 

8 

$0046 

•reserved  for  Apple  use  opcode  +  8  bytes  data 

8 

$0047 

♦reserved  for  Apple  use  opcode  +  8  bytes  data 

8 
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Table  B  (cont’d).  PICT  opcodes. 

Data  Size 


Opcode 

Name 

Description 

(in  bytes) 

$0048 

frameSameRRect 

rect 

0 

$0049 

paintSameRRect 

rect 

0 

$004A 

eraseSameRRect 

rect 

0 

$004B 

invertSameRRect 

rect 

0 

$004C 

fiUSameRRect 

rect 

0 

$004D 

♦reserved  for  Apple 

use  opcode^’^ 

0 

$004E 

♦reserved  for  Apple 

use  opcode 

0 

$004F 

♦reserved  for  Apple 

use  opcode 

0 

$0050 

frameOval 

rect 

8 

$0051 

paintOval 

rect 

8 

$0052 

eraseOval 

rect 

8 

$0053 

invertOval 

rect 

8 

$0054 

fiUOval 

rect 

8 

$0055 

♦reserved  for  Apple 

use  opcode^'^  +  8  bytes  data 

8 

$0056 

♦reserved  ^or  Apple 

use  opcode  +  8  bytes  data 

8 

$0057 

♦reserved  for  Apple 

use  opcode  +  8  bytes  data 

8 

$0058 

frameSameOval 

rect 

0 

$0059 

paintSameOval 

rect 

0 

$005A 

eraseSameOval 

rect 

0 

$005B 

invertSameOval 

rect 

0 

$005C 

fillSameOval 

rect 

0 

$005E 

♦reserved  for  Apple 

use  opcode®’^ 

0 

$005F 

♦reserved  for  Apple 

use  opcode 

0 

$0060 

frameArc 

rect,  startAngle,  arcAngle 

12 

$0061 

paintArc 

rect,  StartAngle,  arcAngle 

12 

$0062 

eraseArc 

rect,  StartAngle,  arcAngle 

12 

$0063 

invertArc 

rect,  StartAngle,  arcAngle 

12 

$0064 

fillArc 

rect,  StartAngle,  arcAngle 

12 

$0065 

♦reserved  for  Apple 

use  opcode  12  bytes  data 

12 

$0066 

♦reserved  for  Apple 

use  opcode  -i- 12  bytes  data 

12 

$0067 

♦reserved  for  Apple 

use  opcode  + 12  bytes  data 

12 

$0068 

frameSameArc 

rect 

4 

$0069 

paintSameArc 

rect 

4 

$006B 

invertSameArc 

rect 

4 

$006C 

SUSameArc 

rect 

4 

$006D 

♦reserved  for  Apple 

use  opcode^’^  +  4  bytes  data 

4 

$006E 

♦reserved  for  Apple 

use  opcode  +  4  bytes  data 

4 

$006F 

♦reserved  for  Apple 

use  opcode  +  4  bytes  data 

4 

$0070 

framePoly 

poly 

polygon  size 

$0071 

paintPoly 

poly 

polygon  size 

$0072 

erasePoly 

poly 

polygon  size 

$0073 

invertPoly 

poly 

polygon  size 

$0074 

fiUPoly 

poly 

polygon  size 

$0075 

♦reserved  for  Apple 

use  opcode'*’^  +  poly 

$0076 

♦reserved  for  Apple 

use  opcode  +  poly 

$0077 

♦reserved  for  Apple 

use  opcode  word  +  poly 

$0078 

frameSamePoly 

(not  yet  implemented;  same  as  70,  etc.) 

0 

$0079 

paintSamePoly 

(not  yet  implemented) 

0 

$007A 

eraseSamePoly 

(not  yet  implemented) 

0 

$007B 

invertSamePoly 

(not  yet  implemented) 

0 

$007C 

fillSamePoly 

(not  yet  implemented) 

0 

$0070 

♦reserved  for  Apple 

use  op«)de®’^ 

0 

$007E 

♦reserved  for  Apple 

use  opcode 

0 

$007F 

♦reserved  for  Apple 

use  opcode 

0 
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Table  B  (cont'd). 


Name 


Description 


frameRgn 

paintRgn 

eraseRgn 

invertRgn 

fiURgn 

*re8erved  for  Apple 
♦reserved  for  Apple 
♦reserved  for  Apple 
frameSameRgn 
paintSameRgn 
eraseSameRgn 
invertSameRgn 
fillSameRgn 
♦reserved  for  Apple 
♦reserved  for  Apple 
♦reserved  for  Apple 


rgn 

rgn 

rgn 


rgn 

rgn  3  . 
use  opcode  ’  +  rgn 
use  opcode  +  rgn 
use  opcode  +  rgn 
(not  yet  implemented  - 
(not  yet  implemented) 
(not  yet  implemented) 
(not  yet  implemented) 
(not  yet  implemented) 
use  opcode^’ 
use  opcode 
use  opcode 


same  as  80,  etc.) 


♦BitsRect 

♦BitsRgn 

♦reserved  for  Apple 


copybits, 
copybits, 
use  opcode 


rect  clipped® 
ren  clipped® 

2  bytes  data  length  +  data 


♦reserved  for  Apple  use  opcode  -f  2  bytes  data  length  +  data 


♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 
♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 
♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 
♦reserved  for  Apple  use  opcode  word  -i-  2  bytes  data  length  +  data 


♦PackBitsRect  packed  copybits,  rect  clipped 

♦PackBitsRgn  packed  copybits,  rgn  clipped 

♦reserved  for  Apple  use  opcode  2  bytes  data  length  +  data 


♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 
♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 
♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  +  data 
♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  -f  data 
♦reserved  for  Apple  use  opcode  +  2  bytes  data  length  -t  data 


ShortComment  kind  (word) 

LongComment  kind  (word),  size  (word),  data 

♦reserved  for  Apple  use  opcode  2  bytes  data  length  +  data 


♦reserved  for  Apple  use  op«)de  +  2  bytes  data  length  +  data 


Data  Size 
(in  bytes) 

region  size 
region  size 
region  size 
region  size 
region  size 
region  size 
region  size 
region  size 
0 
0 
0 
0 
0 
0 
0 
0 

variable® 
variable® 
2-f  data 
length 
2-t-  data 
length 
2+  data 
length 
2+  data 
length 
2+  data 
length 
2+  data 
length 
variable® 

Q 

variable 
2+  data 
length 
2+  data 
length 
2+  data 
length 
2+  data 
length 
2-1-  data 
length 
2-t-  data 
length 

2 

4+  data 
2-1-  data 
length 

2-1-  data 
length 


Table  B  (cont’d).  PICT  opcodes. 


Opcode 


Name 


Description 


Data  Size 
(in  bytes) 


$00B0 

$6ocp 

$00D0 

$00FE 

$00FP 

$0100 


•reserved  for  Apple  use  opcode®’^ 

•reserved  for  Apple  use  opcode 

•reserved  for  Apple  use  opcode  +  4  bytes  data  length  -t-  data 
•reserved  for  Apple  use  opcode  +  4  bytes  data  length  -t-  data 
opEndPic  end  of  picture 

•reserved  for  Apple  use  opcode^ +  2  bytes  data^ 


0 

0 

4  -t-  data 
length 
4  -t-  data 
length 
2 


$01PP 

•reserved  for  Apple  use  opcode  2  bytes  data^ 

2 

$0200 

•reserved 

for 

Apple  use 

opcode 

+ 

4  bytes 

data^  4 

$0BPF 

•reserved 

for 

Apple  use 

opcode 

+ 

4  bytes 

data^  22 

$0C00 

HeaderOp 

opcode 

24 

$0C01 

•reserved 

for 

Apple  use 

opcode 

3, 

V  4  byte£ 

1  data^4 

$7F00 

•reserved 

for 

Apple  use 

opcode 

+ 

254  bytes 

data^54 

$7FFF 

•reserved 

for 

Apple  use 

opcode 

+ 

254  bytes 

data^54 

$8000 

•reserved  for  Apple  use  opcode 

0 

$80FF 

$8100 

$FFFF 

•reserved  for  Apple  use  opcode 

•reserved  for  Apple  use  opcode  4  bytes  data  length  +  data 

•reserved  for  Apple  use  opcode  -f  4  bytes  data  length  +  data 

0 

4  -f  data 
length 

4  +  data 
length 

1.  The  opcode  value  has  been  extended  to  a  word  lor  version  2  pictures.  Remember,  opcode  size  =  1  byte 
for  version  1 . 

2.  Because  opcodes  must  be  word-aligned  in  version  2  pictures,  a  byte  of  0  (zero)  data  is  added  after  odd- 
size  data. 

3.  The  size  of  reserved  opcodes  has  been  defined.  They  can  occur  only  in  version  2  pictures. 

4.  All  unused  opcodes  are  reserved  for  future  Apple  use  and  should  not  be  used. 

6.  For  opcodes  $0040-$0044:  rounded-comer  rectangles  use  the  setting  of  the  OVSize  point  (refer  to 
opcode  $000B). 

6.  For  opcodes  $0090  and  $0091;  data  is  unpacked.  These  opcodes  can  only  be  used  for  rowBytes  less 
than  8. 

7.  For  opcodes  $0100-$7FFF:  the  amount  of  data  for  opcode  $nnXX  =  2  *  nn  bytes. 

8.  See  Inside  Macintosh  (1986). 


14 


Table  C.  Data  format  of  version  2  PICT  opcodes. 


Opcode 

Name 

Description 

$0012 

BkPixPat 

color  background  pattern 

$0013 

PnPxPat 

color  pen  pattern 

$0014 

FillPixPat 

color  fill  pattern 

IF  patType  =  ditherPat 
THEN 

patType;  word;  {  pattern  type  =  2  ) 
patlData:  Pattern;  I  old  pattern  data } 

RGB:  RGBColor;  { desired  RGB  for  pattern  1 

ELSE 

patType;  word;  (  pattern  type  =  1  ) 
patlData:  Pattern;  I  old  pattern  data  ) 
pixMap:  {  pixMap  format  shown  below  1 

colorTable:  {  colorTable  format  shown  below  ) 

pixData:  ( pixData  format  shown  below) 

END; 

$0015  PnLocHFrac  fractional  pen  position 

PnLocHFrac:  word: 

If  PnLocHFrac  <  >  1/2,  it  is  always  put  to  the  picture  before 
each  text  drawing  operation. 

$0016  ChExtra  extra  for  each  character 

ChExtra:  word; 


After  ChExtra  changes,  it  is  put  to  picture  before  next  text 
drawing  operation. 


$001A 

RGBFgCol 

RGB  foreColor 

$001 B 

RGBBkCol 

RGB  backColor 

$001 D 

HiliteColor 

RGB  hilite  color 

$001 F 

OpColor 

RGB  OpColor  for  arithmetic  modes 

RGB: 

RGBColor;  !  desired  RGB  for  foreground/background  ) 

$001 C 

HiliteMode 

hilite  mode  flag 

No  data.  This  opcode  is  sent  before  a  drawing  operation  that  uses  the 
hilite  mode. 

$001 E  DefHilite  use  default  hilite  color 

No  data.  Set  hilite  to  default  (from  low  memory). 

The  next  four  opcodes  ($0090,  $0091,  $0098,  $0099)  are  modifications  of  version  1  opcodes. 
The  first  word  following  the  opcode  is  the  rowBytes.  If  the  high  bit  of  the  rowBytes  is  set, 
then  it  is  a  pixMap  containing  multiple  bits  per  pixel;  if  it  is  not  set,  it  is  a  bitMap  contain¬ 
ing  one  bit  per  pixel.  In  general,  the  difference  between  version  1  and  version  2  formats  is 
that  the  pixMap  replaces  the  bitMap,  a  color  table  has  been  added,  and  pixData  replaces 
the  bitData. 

Note;  opcodes  $0090  and  $0091  are  used  only  for  rowBytes  less  than  8. 
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Table  C  (cont’d).  Data  format  of  version  2  PICT  opcodes. 


Opcode 

$0090 


$0091 


$0098 


$0099 


Name 


Description 


BitsRect 

copybits,  rect  clipped 

pixMap 

colorTable: 

srcRect: 

dstRect: 

mode; 

pixData: 

rect; 

rect; 

word; 

f  described  in  Table  D  ) 

{  described  in  Table  D  I 
(  source  rectangle  1 
{  destination  rectangle  J 

1  transfer  mode  (may  include  new  transfer  modes)  1 
{  described  in  Table  D  } 

BitsRgn 

copybits,  rgn  clipped 

pixMap; 

colorTable; 

srcRect; 

dstRect; 

mode; 

maskRgn; 

pixData; 

rect; 

rect; 

word; 

rgn; 

1  described  in  Table  D  ) 

1  described  in  Table  D  ) 

(  source  rectangle  ) 

(  destination  rectangle  ) 

1  transfer  mode  (may  include  new  transfer  modes)  1 
(  region  for  masking  ) 

1  described  in  Table  D  ) 

PackBitsRect 

packed  copybits,  rect  clipped 

pixMap; 

colorTable; 

srcRect; 

dstRect; 

mode; 

pixData; 

rect; 

rect; 

word; 

1  described  in  Table  D  ) 

(  described  in  Table  D  ) 

{  source  rectangle  ) 

(  destination  rectangle  1 

{  transfer  mode  (may  include  new  transfer  modes)  1 
{  described  in  Table  D  1 

PackBitsRgn 

packed  copybits,  rgn  clipped 

pixMap; 

colorTable; 

srcRect; 

dstRect; 

mode; 

maskRgn; 

pixData; 

rect; 

rect; 

word; 

rgn; 

(  described  in  Table  D  1 
(  described  in  Table  D  ) 

(  source  rectangle  I 

1  destination  rectangel  ) 

(  transfer  mode  (may  include  new  transfer  modes)  ) 
{  region  for  masking  ) 

{  described  in  Table  D  I 
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Table  D.  Data  types  found  within  new  PICT  opcode  listed  in  Table  C. 


Opcode 

Name 

Description 

pixMap  = 

baseAddr: 

long; 

(  unused  =  0  | 

rowBytes; 

word; 

1  rowBytes  w/high  byte  set  ) 

Bounds: 

rect; 

{  bounding  rectangle  J 

version: 

word; 

1  version  number  =  0  ) 

packType: 

word; 

{  packing  format  =  0  i 

packSize: 

long; 

1  packed  size  =  0  ) 

hRes: 

fixed; 

{  horizontal  resolution  (default  =  $0048.0000)  ) 

vRes: 

fixed; 

1  vertical  resolution  (default  =  $0048.0000)  1 

pixelType; 

word; 

(  chunky  format  =  0  ) 

pixelsize; 

word; 

(  no.  of  bits  per  pixel  (1,  2,  4,  8)  ) 

cmpCount; 

word; 

1  no.  of  components  in  pixel  =  1  ) 

cmpSize; 

word; 

{  size  of  each  component  =  pixelSize  for  chunky  1 

planeBytes: 

long; 

1  offset  to  next  plane  =  0  ) 

pmTable; 

long; 

1  color  table  =  0  1 

pmReserved; 

END; 

long; 

1  reserved  =  0  ) 

colorTable  =  ctSeed: 

long; 

1  id  number  for  color  table  =  0  1 

ctFlags; 

word; 

1  flags  word  =  0  1 

ctSize; 

word; 

1  number  of  ctTable  entries  -1  ) 

1  ctSize  +  1  color  table  entries  ) 

(  each  entry  =  pixel  value,  red,  green,  1 

1  blue:  word  ) 

END; 

pixData:  If  rowBytes  <  8  then  data  is  upacked 

data  size  =  rowBytes*  (bounds,  bottom-bounds,  top) ; 

If  rowBytes  >  =  8  then  data  is  packed. 

Image  contains  (bounds,  bottom-bounds,  top)  packed  scanlines. 
Packed  scanlines  are  produced  by  the  packBits  routine. 

Each  scanline  consists  of  [byteCount]  [data]. 

If  rowBytes  >  250  then  byteCount  is  a  word,  else  it  is  a  byte. 


